Instructions on network port opening¶

Quectel PI The current project uses an RK3576 + Debian 13 (trixie) system. A port “being in the listening state” and “being externally accessible” are two different concepts: the former is determined by the service’s binding address, while the latter also depends on the interface, IP address, routing, and on-site network policies.

💡 No IPv4 connections have been established on the network interfaces: end0 and wlan0 are DOWN, while usb0 has only an IPv6 link-local address. Therefore, “externally reachable” in the table below indicates only the service’s binding scope.

Port Opening Principles¶

The development board’s default port policy follows the principle of least exposure: only services that need to be accessed by external hosts listen on all network addresses or on a network interface address; services intended solely for internal system calls listen on loopback addresses. Ports on loopback addresses can be accessed only from the development board itself. Even if such a port is listening, it does not mean that an external host can access it.

After the device connects via Ethernet, Wi‑Fi, USB gadget, or a cellular network, whether a service can be accessed externally also depends on the service’s binding address, whether the network interface has obtained a valid IP address, whether the network route is reachable, and whether the on-site network is subject to restrictions imposed by an upstream firewall, router, or carrier.

Default Listening Ports¶

Protocol/Port	Listening Address	Service/Purpose	Current Verification Result
TCP 22	`0.0.0.0` / `::`	OpenSSH remote login	`ssh.service` is active/enabled; runtime logs confirm that it listens on all IPv4/IPv6 network addresses. External reachability must be verified after the network is connected.
TCP 5037	`127.0.0.1`	ADB local service	`adbd` is bound only to the loopback address and cannot be accessed externally as a network port; in this test, the host connected to the development board via USB ADB.
UDP	No application service listener detected	—	`ss -lntup` showed no UDP listener for application services.

Common Service Ports Not Open by Default¶

Apart from the runtime listeners listed above, no evidence of RDP, VNC, or Web Server listeners was found in this test. The common ports 3389 (RDP/xrdp), 5900 (VNC), 80 (HTTP), and 443 (HTTPS) may listen and become externally accessible only after the user installs, enables, and configures the corresponding services. If application services are enabled later, refer to ss -lntup on the board and the service binding configuration.

Access Boundary Description¶

External network ports: Services that listen on 0.0.0.0, [::], or a specific network interface IP address, with the device reachable over the network. TCP 22 on the M2 in this test meets the condition of being “bound to all network addresses.” However, because end0 and wlan0 have not obtained IPv4 addresses and usb0 has not been configured with IPv4, external connectivity verification has not yet been completed.

Local loopback ports: Services that listen on 127.0.0.1, 127.0.0.53, 127.0.0.54, or ::1. TCP 631 and TCP 5037 on the physical device tested here fall into this category and can be accessed only by processes running on the development board itself.

Security Notes¶

The SSH port is intended for development and maintenance scenarios. If remote login is not required in the final product scenario, the customer or project integrator can disable the SSH service or restrict access sources according to the applicable security policy. System ports bound to loopback addresses by default should not be changed to listen externally, so as to avoid retaining unnecessary debugging interfaces in the image.